Virtualization of hardware has provided numerous benefits with respect to managing large-scale computing resources for many clients with diverse needs, allowing various computing resources to be efficiently shared by multiple clients. For example, virtualization technologies may allow a single physical computing machine to be shared among multiple users by providing each user with one or more virtual machines hosted by the single physical computing machine, with each such virtual machine being a software simulation acting as a distinct logical computing system that provides users with the illusion that they are the sole operators and administrators of a given hardware computing resource. Furthermore, some virtualization technologies are capable of providing virtual resources that span two or more physical resources, such as a single virtual machine with multiple virtual processors that spans multiple distinct physical computing systems. With virtualization, the single physical computing device can create, maintain or delete virtual machines in a dynamic manner. In turn, users can request computer resources from a service provider and be provided with varying numbers of virtual machine resources on an “as needed” basis or at least on an “as requested” basis.
In some virtualization systems, multiple guest virtual machine (VM) are instantiated on a physical host. These VM instances may be managed using a virtual machine manager (VMM) or hypervisor executing on the host. The VMM presents each virtual machine a sandbox of hardware resources. By design, each guest VM is oblivious to the other guest VMs that are co-located on the same host. Nonetheless, because some hardware resources on the host are necessary shared among the co-located VMs, information leakage may occur across the VMs. In particular, some hosts employ a shared last level cache (LLC) of the central processing unit (CPU). The LLC thus includes cached data for all guest VMs residing on the host. This shared cache may be exploited in a form of “side-channel” attack, in which an attacker VM is able observe the interactions between a victim VM and the shared cache. The manner in which the victim VM uses the cache may reveal confidential information, such as for example encryption keys employed by the victim VM.
A number of strategies have been proposed to defeat this type of attack. However, these strategies generally involve drawbacks. The first approach is to avoid co-location of VM instances entirely. However, this approach is not realistic in view of the extensive sharing of hardware that exists in modern, large-scale virtualization systems. A second approach involves a partitioning of the cache among the different guest VMs, which essentially unshares the cache. However, such partitioning reduces the effective size of the cache and increases wastage. In some systems, cache partitioning is incompatible with the use of larger page sizes, which is often used virtualization systems. Other approaches have been proposed to mask the activities of the victim VM so that useful data cannot be extracted from observations of its cache usage. However, these strategies are only useful to defend against the extraction of a particular type of data; they do not eliminate the shared cache as a potential channel of attack. A practicable defense to the use of the shared cache as a general channel of attack remains a significant challenge.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.
It will also be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first contact could be termed a second contact, and, similarly, a second contact could be termed a first contact, without departing from the scope of the present invention. The first contact and the second contact are both contacts, but they are not the same contact.